The present invention relates to project management systems and more particularly to complex project management systems for large organizations.
Project management is sometimes employed by corporations to ensure timely completion of product development, construction and just about any plan requiring the utilization of multiple personnel and resources. Typically, employees with differing skill sets are selected for a project, a project leader is assigned, whom the employees report to, and the project leader establishes a schedule. The schedule details all of the necessary tasks and completion dates necessary for project success. Tasks are assigned by the project manager to employees based on their skill set. The project manager keeps track of the progress of the various tasks and attempts to remedy situations that can cause the project to fall behind schedule.
Professor John Fondahl of Stanford University developed, in the 1960's, a theory he called the “Circle and Connecting Line Diagram”, later termed the Critical Path Method or “CPM”. The Program Evaluation and Review Techniques or “PERT” method, developed at about the same time, is functionally equivalent, although it represents activities as the links between event nodes, rather than as the nodes. Both of these methods state that any project has a start and an end, and that in between the start and the end there are multiple, sequential tasks to complete. These tasks follow multiple parallel paths and combine at least by the finish. The path that takes the longest is termed the critical path and it dictates how long the project will take to complete.
A drawback of the Critical Path and PERT models is that the theories embodied in those models assumes a certain degree of independence of the various activities, that is, they only allow for precedence interdependence. However, this tends not to be the case with many knowledge work products. As such, some experts are not surprised that upwards of 50% of all projects do not get completed on time.
In a traditional work environment, a worker has at least one manager to whom they go to if they have a problem with an assigned task. In the best of all possible worlds, workers are able to complete their assigned tasks without any problems. However, in the real world, problems occur and the workers often discover that they cannot complete their work by the due date due, for example, to technical or coordination problems. In such situations, the workers will typically interface with their manager(s) in an attempt to address the issue at hand. The manager then might coordinate with other personnel to resolve the worker's issue or not address the issue. This is an example of coordination interdependence. In the latter situation, the worker will wait a certain amount of time and try to complete their task, absent input from their manager. This is an example of wait interdependence. The worker may be able to complete the task but there is a chance that it will not be done properly and rework will have to take place. This is an example of rework interdependence.
During implementation of project schedules using the relatively simplistic Critical Path Model and PERT model, the various factors listed above are not taken into account and these factors can ultimately lead to projects schedules that are systematically optimistic due to deficiencies in the model. Commercially available project management software tools typically assume independence of the various activities on the paths to completion, notably Microsoft Project and similar products by the Primavera and Artemis corporations.
Several existing tools, such as Microsoft Project and Primavera's P3, implement the traditional CPM-PERT theory project management. They define projects and allow description of sets of multiple projects. Within a project, tasks have assigned resources. They implement the CPM algorithm to generate a Gantt chart given a task plan and specified resource size. Using the CPM algorithm, projects fall within at least one path between a program start and a program finish. Each project has at least one task. They allow definition and editing of projects, tasks and resources. Resources can be assigned from a pool of named individuals. Some of these tools allow users to define one or more “Work Breakdown Structures” for the project or program organization, into which individual resources can be assigned at a particular level. This structure provides a way to define one-dimensional or multi-dimensional hierarchy of resources for purposes of aggregating data. However, these tools do not handle multiple interdependencies of tasks within a multiple project environment.
In the late 1980's through early 1990's, Stanford researchers including Professor Raymond Levitt and Drs. John Kunz and Yan Jin postulated that the various paths to project completion are often multiply dependent upon each other. By taking this approach they were able to lay the groundwork for VitéProject version 1.0 (released in 1998) and VitéProject version 2.0 (released in 1999) of the Vité Corporation of Mountain View, Calif. These products incorporated multiple relationships between activities that modeled information exchange and failure propagation dependencies between parallel activities, and thus were able to successfully model complex path interactions, in order to produce a more reliable and realistic project modeling.
While the VitéProject versions 1.0 and 2.0 were great leaps forward in project management tools, there are still other factors, which affect proper project management. One of these is the existence of other projects in an organization. These multiple projects very often have overlapping team members, causing an inter-relationship between the projects. That is, if one of the projects requires more time of an employee or group of employees than originally envisioned, other project schedules can be adversely affected since the original resources allocated for those projects has now been reduced. The VitéProject versions 1.0 and 2.0 did not address these multiple project issues.
Yet another factor not addressed by previous project management tools is the existence of complex business organizations, such as a matrix organization. A matrix organization is defined as having workers who report to multiple managers. That is, a worker will typically have both a functional manager and one or more project managers. For example, in a computer manufacturing company, a worker might be in the software group, and thus have a software functional manager, or in the hardware group, and have a hardware functional manager. In addition, the worker may be assigned to one or more projects, and thus have one or more project managers as well. This is an example of a two-dimensional matrix organization. Some companies have higher dimensional matrixes, e.g., three or more dimensional matrixes. For example, in addition to a functional and a project manager, the worker might report to a regional manager.
This type of complex organizational structure can present a dilemma for the worker if the worker has a problem that needs to be addressed involving his or her assigned tasks for a project. For example, in the case of a problem the worker must decide with which manager he should interface. Typically, the type of problem, or issue usually dictates to whom the worker should go for help. If it is a technical problem, for example, the worker should go to the functional manager. If it is a scheduling issue, the worker should go to the project manager. The ability to model these interactions is critical to accurately model and simulate a project schedule for complex organizations.
Accordingly, what is needed is a tool to realistically model project management that takes into account the multiple interdependence of project tasks, demand on worker's time from multiple projects, and the ability to handle complex organizational structures.